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(57) Abstract : 

Method for a secure hand- 
shake protocol between A and B, 
connected by a slow channel (Urn). 
A sends a first message (21) indi- 
cating a set of cipher suites with 
parameters, and its identifier (IDa). 
B selects a cipher suite, obtains 
A's certificate (Ca) over a fast 
connection, verities A's certificate 
(Ca) and obtains A*s public key 
(Ea). Next B sends a second mes- 
sage (26) comprising B's certificate 
(Cb), and indication that B has ver- 
ified A's certificate (Ca), and an in- 
dication about the selected cipher 
suite. A begins to use the selected 
cipher suite; verifies B's certificate 
(Cb) and obtains B's public key 
(Eb). Next A sends a third mes- 
sage (28) indicating that A has ver- 
ified B's certificate (Cb). Applica- 
tion data can be sent from A to B 
in the third message (28), whereby 
a two-way key-exchange and mu- 
tual verification is achieved with an 
effective overhead of two messages 
(21, 26) between A and B. 
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Secure handshake protocol 

Background of the Invention 

The present invention relates in general to a secure handshake 
protocol for telecommunications networks. More particularly, the invention re- 
5 lates to a method and an apparatus for providing secure handshake between 
call parties with minimal overhead before actual data transmission. 

Within this application, "TLS" refers to Transport Layer Security. 
One such protocol, is described in "The TLS Protocol", May 21, 1997, by Tim 
Dierks and Christopher Allen, Consensus Development. This document has 
10 been published as "draft-ietf-tls-protocol-03.txt", incorporated herein by refer- 
ence. More particularly, the present invention proposes an improved hand- 
shake protocol which is applicable i.a. in protocols like TLS. 

A TLS-type protocol comprises several layers, such as: 

Upper layer protocols - / 

15 Handshake protocol/Alert protocol/Application protocol 

Record protocol 

Transport protocol 

Lower level protocols 

Figure 1 is based on section 7.3 of said TLS draft protocol,; and it 
20 illustrates a prior art handshake method. In order to keep the specification 
consistent with said draft, parties A and B are also referred to as "client" and 
"server", respectively. (Terms likie "hello"- and "finished" are also used consis- 
tently with said TLS draft:) In Step 11, the client A sends a client hello mes- 
.. sage. This client hello, message comprises a list of cipher suites and icompres- 
25 sion methods supportep\by the client. Additionally, the message may. also 
comprise a time stamp. .In step 12, the server. B selects a cipher suite, and a! 
compression method. (Qptionpily, B may also/check the timestamp. |o make 
. sure that the message'is-not aft old message being retransmitted:) 

In step 13 .the jserveY B responds with a server hello message, The . 
30 client hello and server herlo rriessages 11 and,, 13 establish security between 
.'.the parties, typically by ^stabiishing the following attributes: protocol version; 
; session ID, cipher suite and /compression method. In connection With! the 
1 server hello message,;. the, server B sends its own' certificate C B to the, client A 
and it requests the client, A toi.^end its client certificate C A to the server B. In. , 
35 response to this, in step 14 the client A verifies' B^s certificate and obtains B's 
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public key ;% In step 15 the clierit A sen'cfs B"k finished message^ indicating 
. , that A has been able to verify B's identity. Additionally, A sends jts pwn certifi- 
cate, G A to.B. In step 16, B uses C A to obtain A's public key "E A .Jn step 17, B 
; sepds its own* finished message to the client A. In connection i with , verifying its 
5 peer's identity; each party ; fhdependMly calculates a Shared secret key for 
this session, Now both* parties- have^^e^hanged 'keys/ agreed on a cipher 
_ suite/compression method and venRed" l the idlhtity of the other party. In step 
18, the client A can start transmitting application data. 

An essential component, jn|h^ above . protocqh are the certificates C A 
10 and C B . By means of certificates signed by a mutually trusted authority, each 
■■■ party can verify its peer's 'identity.' A certificate comprises, at least .its owner's 
' . • -■ identity (A/B) and public key(s) (E ^Mj, pelib^ pf validity, the issuer of the cer- 
tificate and the issuer's digital signature. It may also , comprise the rights 
granted to its owner. A suitable mechanism for digital signatures is a reversal 
15 of public-key encryption: the j issuer" iignslHe certificate with Jts, private key and 
whoever wants to Verify tfW/ c^Hi^i&r^ib^ : so by' using the issuer's public 
key:-A suitable structure for a certificate is specified I in ISO standard X.509. 

A problem with this prioi 1 art' handshake protocol is the high over- 
head required. As seen in Fig. JL,'the ? . ^ctual data, transmission ^does^hot begin 
20 until step 15, or after four messages have been transmitted between the par- 
ties: In a Wireless multiple access system, where the parties A and,B are sepa- 
^ rated by an air interface Urn and a public larid based mobile network PLMN, 
the actual messaging is much more cpmplipated .tharj the one shown in Fig. 1. 
this is because Fig. 1 only shows the actual messages and omits (for clarity) 
25 the resource reservation and release .steps, which are routine for a person 
stilled* in the art, but which are neve^hjjf.s.s. indispensable. ,• 

- ., \ Disclosure of the Invention •>•:*. ;-v v l 

>'■'•'--' ' Based on the foregoing description, it is an object of the present in- 
vention to create a method and suitable network elements (nodes and termi- 

30 -rtals) for providing a secure handshalce'p^ overhead, i.e. a 

small number of messages over the air interface, this object will be achieved 
v with a method 'and network elements which are characterized by what is dis- 
closed in ; the appended ^ embodiments of 

.' • the present invention will be prese'ntedln the dependent claims. 

35 ' the invention is based on a hovel d 

tweeh the parties A and B. in additi6ri; u some messages over the air interface 



WO 99/25093 



3 



; . PCT/FI98/00869 



- ,-, °?r Eliminated bousing a land-based certificate store\or service, and per- 
. an jnquiry to this sjpre, further, .the invention is based on' the vision 

' that the iasj message of the handshake proper, should be sent from A to B, 
^whereby "actual data transmission, can be concatenated.- with the last hand- 
5 shake message, .whereby the net overhead is minimised. ■ . : ■ ' 
''' ' i ^' r Jhe invention to .af^£abfe : *> telecommunication: systems with a 
slow and/or unreliable ^.transmission, channel acting- asa bottleneck between 
the parties. . . . .- { . 

•-•* ■ > " Brtef Description' of the drav/mgs 

10- ' . ;. " '"' ,n * ne , foirowin^,th'f> inveption will, be described; by means of pre- 

,.' t J** 6 ^ 6 ^f^^^^ n ^k the accompanying drawing, in which: 
. ' ' '. Fi 9 u fe 1 showsJ a signalling diagram illustrating a .prior , art hand- 
shake protocol; and' ' " r . 

.. .T'9 ur f .^:' s , a ^rrjWnatipn .wherein the bottom portion is an inter- 
15 _ leaved signalling diagrarn/flpw^ an ..embodiment of the. invention 

and the top; pp^iori is a .block diagram showing- how the inventive functionality 
can be mapped to ^various netvyork elements. . 

Detailed description of theimVehtion : <: 

Referring now to'Rg. 2, ah embodiment of the invention will be de- 

20 scribed. The lower ; portion r of Tig. ' 2 is ..an interleaved . signalling dia- 
gram/flowcnart Illustrating an' &mb^iment of the invention. The upper portion 
of Fig. 2 is an assoda^ed ,- bl0^diagram,' illustrating' a possible mapping be- 
tween call 'parties and [physical network elements. 

Irt step 21 the client A; sends a first inter-party message "comprising 

25 all the elements of the message of step 1 i*. (An inter-party message is a mes- 
sage from A to B or vice versa.) Additionally, the message of step 21 com- 
prises an identifier ID A of the client. A, and encryption parameters (such as 
random numbers and/or initialisation vectors), if required by any,. of -the indi- 
cated cipher suites! Jhe identifier .ID A will be studied.later in more detail. In re- 

30 sponse to' the client hello message, in step. 22 the , server B selects a cipher 
suite. Preferably, it aiso checks the timestampof the ,message ; sent by A. In 
step 23, instead of requesting'^^ certificate C A from A itself,- the server B uses 
the lb; sent by Ato retrieve A's,. certificate C A from a certificate store CS. The 
connection between. B' and C§ should be significantly faster than the air inter- 

35 face Urn. In step 24, the trustee CS returns A's certificate C A . Alternatively or 
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• additionally? 6 cart also maintain a local memory MEM of certificafes'ind omit 
; the inquiry to C'S if A's certificate is found in the ideal memory. In step 25, B 
•='••* verifies : C A , obtains A's public key E A and calculates the shared secref key. In 
•• step 26, # sends a second inter-party message to A. the second inter-party 
5 message comprises B's certificate C B . It also indicates that B has been able to 
verify A'i certificate. (However, this iridi'catibh can be an implicit one, meaning 
that B only" sends its certificate if it has' verified A's certificate;) In step 27, A 
Verifies B's certificate C B , obtain^ B's public"key E B and calculates the shared 
v; secret key! in step 28, A sends B a third jntsf-party message comprising a fin- 
10- ishe'd-messade whibh indicates thlt'i't has'been able to verity B's certificate.' 

For clarity, Fig. 2 only snows what happens when the handshake is 
succ^ssfulfi.e: both parties' act ^m)rHiWg"ib '%h% 'prdtdbof. _'lf a departure from 
the 'protocol is detected, this is usually a fatal error and the'HantfshaTce termi- 

nates. , 

It should be noted that the ! Idif Intef-party 
finished message in step 2^)' polhte'froWA : ^o 'B'/Thls'is in marked contrast to 
the' prior art handshake shown in Fig?i / Ah advantage' of this property of the 
invention is that application data ■cah v be c 'ffie^nrited Wltri : fte third inter-party 
message in step 28. Thus the effective "overhead of the handshake protocol 
'20" according to the invention is only two inter-pally messages; compared to an 
overhead of four messages in trie 'frlo?a#Mhtishake»; In order to achieve this, 
«•'' ~an r appropriate key exchange hechahisrn must be used. Suitable key ex- 
change algorithms include Diffie-Hellman (DH) with fixed parameters certified 
with Digital Signature Algorithm (DSA) The DH algorithm can be found in most 
25 textbooks on' cryptography. Additionally/ the i original Diffie-Hellman algorithm 
• (DH) is' described in US f Patent 4 200 770 and the Digital Signature Algorithm 
1 (DSA) is a U.S. standard and a de facte i international standard. Another good 
• ' ; combination is Elliptic Curve Diffie-Hellman (ECDH) with fixed parameters cer- 
tified with Elliptic Curve Digital signature Algorithm (ECDSA). The difference 
36 '' between standard DH and ECDH is only different mathematics in A obtaining 
and using encryption and decryption keys: buch differences are not essential 

to the invention. \ , 

'•' • Additionally, RSA (Rivest-ShamV-Adlemahri) and ECES (Elliptic 

: Curve Encryption Scheme) algorithms can be used with appropriate modifica- 
! 35 tions. With these algorithms, a server "key exchange takes place as follows. B 
generates a random number, which is a pre-master secret, encrypts it with A's 
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. public key, and .sends the. result ..tp. A., Thus the message, in. step 26 would 
... c cprnprise SeryerHello, C B , ?erye.rKeyExchange, Finished. Now A .decrypts this 
. ^ pre-master. secret. This server key exchange procedure resembles, a mirror 
. .image of the ona used in TLS, whereby the handshake pap still, be., accom- 
^5 plished with two messages oyer the air. interface. ; ,., ....... 

, : , rjhe hand^ake^ method described above uses public keys. As is 
. well known, pubiic-key, cryptography is much .slower than symmetric eryptog- 
' raphy. Therefore, it is, preferable to use the public-key handshake only for ex- 
changing parameters, which are used for computing a shared key.for .symmet- 
io " rip. cryptography,, such, as .PES., The.,parameters , (ranc|pm ..numbers) . : sent in 

.message 21 can be used, for this, purpose 

, _ Althou5h^^e ; ,jm/enJye .handshake '.somewhat limits 4he .available 
keyrexchange mechanisms during the handshake phase, the invention does 
not limit the available mechanisms used for the actual data transmission. In 
P i 5 „ other words,, thjs jn\(e^ . limit the choices available for symmetric 

^cryptography,, although jt require? that the, parameters for the symmetric cryp- 
tography first used , are key^exchange mechanism with 
fixed parameters. The encryption. parameters sent in, message 21 (and;26) can 
, ^ be combined yyjth^priyate^eys. v tQ. create pre-master secrets which, in turn are 
20 used to create master secrets,: etc. Thus, to each .application data message 
following message. 28,,, a separate message can be concatenated. This sepa- 
. rate message, can be used for changing the selected cryptography, mecha- 
nism. . - 

The identifier ip A pf client, A should -be unique to each A. Suitable 
25 identifiers are e.g. a network number, such as, M^ISDN or. an X. 509. number. 
The ID A is not protected byJhjB- handshake protocol proper, although it } may be 
prptected by a lower level protocol. Therefore, it is preferable to create the ID A 
using a one-way funption^ such as a hash function. One-way functions are 
functions, that are muph, easier, (fit .least by several orders of magnitude) to 
30 perform, in ope dirertion.than .in the reverse direction. Examples of one r way 
functions are multiplying. Iargp r prime numbers, discrete exponentiation, ellipti- 
cal functions and hash functions. The advantage of one-way functions is that 
they hide the identity of A JtPm. possible eavesdroppers, As is well known, 
hash functions reduce. information. Hashed numbers are„thus not necessarily 
35 unique.. However, r a,aood combination is. achieved by using a hash of the cli- 
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enf^^ublid key E A and assigning public keys such thai they do not produce 
identical hash values. - 

The upper portion of Fig. 2 shows how the functionality of the in- 
vention can be mapped to various network elements. The invention can be 
5 used in a wireless communication system, such as a mobile communications 
system. The client A can be a mobile station MS, possibly having a portable 
computer PC connected or integrated thereto. The server B can be a com- 
puter B' providing financial services, or granting access to confidential infor- 
mation, etc. A and B can communicate over an air interface Um and via a pub- 
10 lie land based mobile network PLMN, possibly also via a public switched mo- 
bile network PSTN, 

The trustee CS could be implemented in one of the registers of the 
PLMN, such as a home location register (HUR), or a GPRS register GR. Alter- 
natively, the trustee services can be implemented as disclosed in said ISO 
15 standard X.509. 

Instead of retrieving A's certificate from CS, or in addition to it, B 
can maintain a local memory MEM of certificates and omit the inquiry to CS if 
A's certificate is found in the local memory. B can e.g. be connected to a local 
area network and the certificates of all the clients A are maintained over the 
20 local area network. A local memory MEM can also be used as a cache mem- 
ory for storing recently used certificates. In real-time applications, if a certifi- 
cate is revoked, the computer B' must be informed and it must also delete the 
revoked certificate from its cache. 

An important advantage of the invention is that the overhead over 
25 the slow communications channel, such as the air interface, can be halved 
compared to prior art protocols. Another advantage is that the client's certifi- 
cate C A does not have to stored in the client itself. Since the client A is typically 
a mobile station, its memory capacity is limited- This also reduces the informa- 
tion gained by dishonest third parties in case the client hardware gets lost or 
30 stolen, or is used by unauthorised persons. Also, because the client's certifi- 
cate C A is not transmitted over the air interface, less information is leaked to 
possible eavesdroppers. 

The invention has been described in its preferred embodiments. 
However, the specifications for telecommunications technology are developing 
35 rapidly. Such developments may require additional modifications to the inven- 
tion. Therefore, all words and expressions should be interpreted broadly, and 
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*hey are intended for ijlystratjng. rather tj}a,n limiting the invention as specified 
in the appended claims. 
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Claims: ' ' ''' ' : ' ' ' . 

' " 1. A method for a secure handshake protocol between a first party 
(A) and a second party (B), connected via a communications channel (Urn, 
PLMN) wherein each party supports a respective set of cipher suites and for 
each party, a. respective cepcatei;(C A , s C B ),is defined, eack of, the certificates 
(C A , Cg) comprising a public key (E A , E B ) ft ofits respective, ;pwner, (A, B); the 
method being characterized in that 

' ! the first party (Apserids r al first ' infer-party message (21) indicating 
theiset of cipher suites supported by it; parameters ^required by the cipher 
suites, and an identifier (ID A ) of the first party (M 

in response to the first inter 7 party message (21), the second party 

- selects one of said indicated cipher suites which is also supported 

by the second party (B); 

- uses said- identifier (I D A ) , to r pbtein|4he, certificate (Ca) of the first 
party (A) over a connection which is~signifipantly faster -than the communica- 
tions channel (Urn, PLMN) -connecting, said. parties; , v - : •> 

,,. - verifies said, obtained ^.rt^t^,(-p A )-the.of the.first.party (A) and 
obtains the public key (EJ of the first party (A); 

"• -'sends a McoMihterHjarty'^e^sage (26) comprising the certificate 
■ (C B ) of the second party (B), an indication that the second party (B) has veri- 
fied the certificate (C A ) of the .first ■ party 5 <A)t and an indication about said se- 
lected cipher suite; 

in response to the second iriter-party message (26), the first party 

- begins to use the selected cipher suite; 

., • ) \ i ■> l verifies the certificate (C B ) of the i second parfy (B) and obtains the 
public key (E B ) of the second party (B)^ J ^ ' : i ' ^ w 

. - - sends 'a -third inter-party : nie%'sa^e'(28)" indicating that the -first party 
I : (A) has verified the certificate- (Cg)%f the^sdcohd party (B)< ; - i 

whereby information not needed for \tne l above steps can be sent 
from the first party (A) 'to the second 'party (B) in the third inter-party message 
(28), thus providing a two-way key^excharige ? and mutual verification with an 
effective overhead of two inter-party rTie^siges f21v 26). ^ u 



* 



Wp 99725093 ^ ^ r t PPT/FI98/00869 

9 



2. A method according to claim 1 , characterize d:jn that said 
^ step of obtaining the certificate (C A ) of the first party (A) comprises retrieving it 
' from a source (CS) external to the second party. 

: - x ' - 3. A method according to claim 2, charac tex i 2 ed in that said 

5 - -external source (CS) is a Register ^(HLR f : 'iSR) of a telecommunications network 
or a directory service substantially ednforr^ing to lSO'staHdard X.509. * 

.'-'\\: • r • • : . - , , 

, 4 r. A method according: to, claim 1 , c tva r a,c t<? r i z e d in that said 

■step of obtaining the certificate (C A ) of : the first party (A) .comprises retrieving it 
from a local memory (MEM>. : ; , r ;;. - • , ; ,y t _ v: 

10 5. A method according to any one of the preceding claims, char- 

acterized in that said identifier (ID A ) of the first party (A) is formed by 
means of a one-way function, "preferably a hash function. 

6V A meth6d%ebordih^ to any one of the preceding claims, char- 
a cte riz : ecJ in that said' second inter^party message (26) comprises a pre- 
15 master secret which the second party (B)' obtains by (generating a random 
1 ^ number and encrypting it \Ariththe public key (E A ) of the first party (A). 

• . 7. A telecommunications^ apparatus (A) being adapted to act as a 

, ,j first party in a secure handshake protocol between said apparatus; (A) and a 
. second party (B), , said apparatus, being chajaxte ri zed;; in that it is 
20 adapted to: t f . , > : . 

f . -.send a first -message (21) to : ,the, second . party (B), said first mes- 
sage indicating a set of cipher suites, parameters required by said cipher 
suites, and an identifier (ID A ) of the apparatus (A); . 

-.receive a second message (26) fronrnthe second party (B), said 
25 second message comprising an indication about ;a> cipher suite s ^elected by 
. said second, party, ^a^rtificate^CCB) of the second party, an indication that the 
second party (B) has ;usecLsaid identifier fiD^ pf the, apparatus to obtain and 
verify ^certificate (C A ) of the apparatus (A), and; 

t - use thepipher suite indicated by said second message (26); 
30 v : v ^verify the certificate. (C B ) ( . of the. second party (B) and obtain a pub- 
lic key (E B ) of the second RartyJB);; , / - 
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- send a third message (28) to the second party (B), said third mes- 
sage indicating that the apparatus (A) has verified the certificate (C B ) of the 
second party. - , 

8, A telecommunications "apparafus^A) .acrordinfl to claim 7, 
5 characterized by being adapted to insert information' not needed for the 
above operations in said third message (28). 

; g;A telecommunications apparatus (B) being adapted to respond to 
a secure handshake protocol initiated by a first party (A), skid apparatus (B) 
being connectable to said first party (A) by a communications channel (Urn, 
10 PLMN), said apparatus (B) „heing c h;a,r.a c t e r i zed in that it is adapted to: 

- receive a first message (21) from the first party (A), said first mes- 
sage indicating a set of cipher suites, parameters required by the cipher 

■« suites, and an identifier (ID A ) of the first party (A); 

- select one. of said indicated cipher suites; 

15 : - use the identifier (ID A ) to obtain p certificate (€*) of the first party 

(A) over a connection which is significantlyjf aster than said communications 

channel (Urn, PLMN); fj- ; 

- verify said obtained ce#cate/(G A ) of the first party (A) and obtain 

a public key (E*) of the first party (A): 
20 . send a second message (26) to the first party (A), said second 
message comprising a certificate (C B ) of the apparatus (B), indicating that the 
apparatus (B) has verified the certificate (C A ) of the first party (A),, and indicat- 
ing said selected cipher suite; 

- receive a third message (28) from the first party (A), said third 
' 25 message indicating that the first party (A) has verified the certificate (C B ) of the 

apparatus (B). 

\ ; .10. A telecommunications apparatus (B) according to claim 9, 

1 -characterized by being adapted -to extract information not needed for 
the above operations from said third Message (28) . 
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Verify Ca, obtain Ea; calculate shared secret 
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Verify Ca, obtain Ea, calculate shared secret 
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